The subject matter disclosed herein relates to device control systems and, more particularly, to an improved system and a method for distributed lighting control.
Traditional light control systems used in buildings are built with load actuators, such as relays and dimmers circuits and user interfaces such as keypads and sliders. Higher level appliances, such as PCs and tablets, can be used for visualizing the state of the lights and for allowing another means to control the light settings. In distributed light control systems, these elements are connected with each other through a network. These systems are built on a distributed architecture where user interfaces and load assemblies can be distributed throughout a space. Unlike a centralized controller, this distributed architecture avoids the need that all light loads and user interfaces be hardwired to the centralized controller thereby saving the cost of having to pull all load carrying cables to the controller and if wireless networks connect the devices, further saving the cost to pull the networking cables between the devices. Another advantage of a distributed architecture is that there is more flexibility during the project installation and post-installation to make changes to the system as these systems are less dependent on the said cables.
Such systems are built with a large number of different devices built to be interoperable with each other, meaning that they can communicate with each other via a network. If such devices are capable to directly communicate with each other via a common network protocol, they are generally perceived to form a product family.
The network protocol for traditional lighting solutions contains two categories of network commands. The first category are the control commands, such as toggling of a light circuit, setting an absolute setting such as OFF, ON or a dim setting or requesting a light scene that is addressing a group of light actuators. A second category of commands addresses the need to send the current status of the light actuator back to the user interfaces. This second command type is used so that, for example, the user interfaces can indicate the brightness of the light with an LED light bar or with a fill-bar on an LCD of a PC or tablet. This feature can be achieved by requiring the user interfaces to poll the load actuating devices for the current state of the load. Another method is where the load actuating device sends the device status to the user interfaces on its own without requiring to be polled.
The limitation of this second type of command lies in the difficulty in scalability to larger automation solutions. If a user interface launches a control command to N load actuators which in turn need to report their actuator settings to M different user interfaces, an N×M scaling relationship results where, if not properly designed, the network traffic will be very substantial and would lead to systems with high latencies. Even if a broadcasting or multicasting method is used to send the controlling command, many actuators will need to update all the user interfaces with their new state at once, thus the multitude of actuator status information will burden the network. Accordingly, a new and improved distributed lighting architecture is required.